一段歷史

• 很久以前，待過一個行雲流水的團隊，三個月做完一個彩票，再三個月上線一個包網，做包網的同時還一起運維彩票
• Kick-Off 的時候
  • 產品經理 調研後做出 Wireframe 與 設計師 還有 後端工程師 確認操作流、邏輯流和資料流，然後各自實作
• 第二階段，前端工程師 與 測試工程師 進場
  • 後端工程師 提供 Mock API 與 前端工程師 確認功能細節
  • 設計師 與 前端工程師 交換使用者介面與體驗的流程與意見
  • 測試工程師 與 產品經理 確認功能然後開始寫測試案例
  • 產品經理 統整這四者之間的進度與優先序
• 第三階段，產品原型出來，運維工程師 進場
  • 設計師 跟 前端工程師 持續保持溝通協作
  • 後端工程師 與 前端工程師 在當時預定義好的 API 持續改進修正，後端工程師 另外補足邏輯流資料流細節
  • 測試工程師 開始進行測試然後瘋狂開單
  • 產品經理 除了關注整體進度外，開始準備測試環境上線需要配合的事宜
  • 運維工程師 準備部署細節
• 第四階段，測試環境上線，可能開始需要對接外部系統
  • 測試工程師 確保主功能測試覆蓋度，有問題立刻開單，前端工程師 和 後端工程師 進入開單關單的循環
  • 產品經理 搜集反饋與測試結果，確保測試環境如期交付
  • 設計師 準備下一階段皮膚與介面優化調整
  • 運維工程師 維運測試環境、準備正式環境與協助工程師們除錯
• 第五階段，正式環境上線
  • 以上就是跟 API 驅動開發比較相關的部分，後面我先省略 ...

API 驅動開發，API Driven Development

• 當年其實沒有發現到那個有效率的團隊用的就是這個方法，我們當時其實用「後端先行」來稱呼
• 但我並不是讀很多書的人，知識與經驗比較偏向由實踐所得而來，所以這邊我想分享 Andrew 哥的一場分享
  

幾個重點

• 這並不是一個側重後端的開發方法，也不是代表後端比前端重要，而是過去我們在追求最小 idle time 的一個過程
• API 就像是個合約，變動他有成本，所以需要良好的預先設計保持彈性
• API 需要維運，後面其實需要一個 Server 實體跑邏輯流和資料流，做出對應操作或是回應資料
• API 有資安議題，無論是驗證與授權
• API 需要監控，這樣才能知道實際使用的狀況以及意外處理
• 還有很多內容無法一次概括，更深的內容非常推薦 Andrew 哥相關的演講內容

✌️ 那麼第三天到這邊囉，明天來講 -> 產品原型，Prototype

相關資訊

• $_purefunc 純函式公司
• FooTinder App站
• FooTinder App 下載連結